In today's high-traffic internet, it may be desirable to have multiple servers representing a single logical destination server to share load. A typical configuration may include multiple servers behind a load-balancer to determine which server will service a client's request. Such hardware may be expensive, may have a rigid policy set, and may be a single point of failure. An alternative load-balancing architecture, using an OpenFlow switch connected to an OpenFlow controller (such as a NOX controller), may provide increased flexibility in policy, reduced costs, and/or potential to be more robust to failure with future generations of switches. OpenFlow architectures are discussed, for example, by: Uppal, Hardee et al., “OpenFlow Based Load Balancing,” University of Washington, http://people.cs.umass.edu/˜hardeep/cse561_openflow_project_report.pdf, 7 pages, reproduced Jun. 27, 2013; McKeown, Nick et al., “OpenFlow: Enabling Innovation in Campus Networks,” http://sb.tmit.bme.hu/sonkoly/files/openflow/openflow-wp-latest.pdf, 6 pages, Mar. 14, 2008; and “OpenFlow Switch Specification,” Version 1.1.0 Implemented (Wire Protocol 0x02), 56 pages, Feb. 28, 2011. The disclosures of all of the above referenced documents are hereby incorporated herein in their entireties by reference.
An OpenFlow switch (also referred to as a switch) is similar to a standard hardware switch with a flow table used to perform packet lookup and forwarding. The difference lies in how flow rules are inserted and updated inside the switch's flow table. A standard switch can have static rules inserted into the switch or can be a learning switch where the switch inserts rules into its flow table as it learns on which interface (switch port) a machine is. In contrast, an OpenFlow switch uses an external OpenFlow controller (also referred to as a controller) to add rules into its flow table.
An OpenFlow controller is an external controller (external to the switch) that is responsible for adding and/or removing new rules into the OpenFlow switch's flow table. The OpenFlow switch is connected to the controller and communicates over a secure channel using the OpenFlow protocol. Current designs of OpenFlow may only allow one controller per switch. In current load balancer designs using OpenFlow, controller decides how packets of a new flow should be handled by the switch. When new flows arrive at the switch, the packet is redirected to the controller which then decides whether the switch should drop the packet or forward it to a machine connected to the switch. The controller can also delete or modify existing flow entries in the switch.
The controller can execute modules that describe how a new flow should be handled. This may provide an interface to write C++ modules that dynamically add or delete routing rules into the switch and can use different policies for handling flows.
A flow table entry of an OpenFlow switch includes header fields, counters, and actions. Each flow table entry stores Ethernet, IP and TCP/UDP header information. This information includes destination/source MAC and IP address and source/destination TCP/UDP port numbers. Each flow table entry also maintains a counter of numbers of packets and bytes arrived per flow. A flow table entry can also have one or more action fields that describe how the switch will handle packets that match the flow entry. Some of the actions include sending the packet on all output ports, forwarding the packet on an output port of a particular machine and modifying packet headers (Ethernet, IP and TCP/UDP header). If a flow entry does not have any actions, then by default, the switch drops all packets for the particular flow.
Each Flow entry may also have an expiration time after which the flow entry is deleted from the flow table. This expiration time is based on the number of seconds a flow was idle and the total amount the time (in seconds) the flow entry has been in the flow table. The controller can chose a flow entry to exist permanently in the flow table or can set timers which delete the flow entry when the timer expires.
Because an OpenFlow controller is external to (i.e., separate and/or remote from) an associated OpenFlow switch, delay/latency may result for communications between the controller and switch, thereby delaying transfer of data packets to the intended servers.